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DETAILED ACTION 

1. Claims 1-48 are pending in tliis application. Claims 1-6, 9-10, 14-15, 18-19, 21, 
25-44 and 46-48 are amended as filed on 17 November 2008. 

Claim Rejections - 35 USC §112 

2. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
mailing and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

3. Claims 1, 14, 19, 25, 34, 40, 44 and 46 are rejected under 35 U.S.C. 112, first 
paragraph, as failing to comply with the written description requirement. The 
claim(s) contains subject matter which was not described in the specification in 
such a way as to reasonably convey to one skilled in the relevant art that the 
inventor(s), at the time the application was filed, had possession of the claimed 
invention. 

4. With respect to Claims 1 , 14, 19, 25, 34, 40, 44 and 46, they recite the limitation 
"bound in part" (see for example. Claim 1 , line 4). There is no disclosure in the instant 
specification regarding a device being bound in part to a port. The instant specification 
deals with binding a device to a port, but this is not the same as a device that is "bound 
in part" to a port. 
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Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1, 10-13, 14, 19-20, 25, 33-34, 40 and 44-46 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Berger (US 2003/0087219 A1) in view of 
Universal Serial Bus Specification Revision 2.0 (April 2000), hereinafter USB 
Spec. 

7. With respect to Claim 1 , Berger disclosed: "A method for synchronizing data on a 
device in communication with a client system ([0035], lines 5-10), said method 
comprising: 

receiving notification that a device ([0082], lines 1-5), in communication with a 
client system via a USB connection ([0041], lines 1-2, specifically USB connection)", 

"mapping, responsive to receipt of the notification ([0082], lines 1-12, where the 
notification causes the device to be mapped), the device into a user session hosted by a 
server ([0082], lines 3-12, where the client device, PDA, is mapped into a user session 
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hosted by a server, [0092], lines 1-13), communicating witli said client system via a 
presentation-level protocol ([0044], lines 2-5, specifically HTTP); 

executing, by said server within the user session, an instance of an application 
([0092], lines 1-13, specifically integration servlet); and 

synchronizing a collection of data on said device with a collection of data 
accessible from said user session as a result of the execution of said application 
instance ([0082], lines 3-12)". 

Berger did not explicitly state: a device "is bound in part to a port number within a 
virtual communication channel". 

However, USB Spec disclosed: a device "is bound in part to a port number (pg 
33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within a virtual 
communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication Flow, lines 
1-6, where the communication is a virtual channel between the client software in the 
host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 
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8. With respect to Claim 14, Berger disclosed: "A method for synchronizing data on 
a device communicating with a client system ([0035], lines 5-10), said client system in 
communication with a server using a presentation-level protocol ([0044], lines 2-5, 
specifically HTTP), said method comprising the steps of: 

determining the identity of a device in communication with said client system 
([0093], lines 4-6); 

determining that the device is a member of a registered device class ([0090], 
lines 1-5, where a device is part of the class of devices that will invoke an agent core if 
the HotSync process is started); 

creating a notification indicating that the device is in communication with the 
client system ([0090], lines 1-5, where a HotSync trigger is started)", and 

"directing the notification to an instance of an application executing within a user 
session hosted by the server ([0091], lines 1-6, where the agent core connects to the 
integration servlet and delivers a message requiring synchronization) and 

synchronizing a collection of data on said device with a collection of data 
accessible from said user session as a result of the execution of said application 
instance ([0082], lines 3-12)". 

Berger did not explicitly state: "and that the device is bound in part to a port 
number within a virtual communication channel". 
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However, USB Spec disclosed: "and that the device is bound in part to a port 
number (pg 33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within 
a virtual communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication 
Flow, lines 1-6, where the communication is a virtual channel between the client 
software in the host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

9. With respect to Claim 1 9, Berger disclosed: "A system for synchronizing data on 
a device in communication with a client system ([0035], lines 5-10), the system 
comprising: 

a client system executing a presentation-level protocol to communicate with a 
server system ([0044], lines 2-5, specifically HTTP), said client system including an 
event manager ([0090], lines 1-5, specifically HotSync Manger) to generate event 
notifications ([0090], lines 1-5, specifically a HotSync Trigger) based on a 
communication received from a device interfacing with said client system ([0090], lines 
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1-5, where, in response to communication from a PDA, the HotSync Manager starts a 
HotSync Trigger); 

the device communicating with said client system ([0041], lines 1-2), and having 
a collection of data ([0040], lines 6-9)", and 

"the server system communicating with said client system via a presentation- 
level protocol ([0044], lines 2-5, specifically HTTP) and hosting at least one user 
session ([0092], lines 1-3), executing an instance of an application used to synchronize 
the collection of data on said device with a collection of data accessible from said user 
session ([0092], lines 5-10)". 

Berger did not explicitly state: "the device is bound in part to a port number within 
a virtual communication channel". 

However, USB Spec disclosed: "the device is bound in part to a port number (pg 
33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within a virtual 
communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication Flow, lines 
1-6, where the communication is a virtual channel between the client software in the 
host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
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communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

1 0. With respect to Claim 25, Berger disclosed: "A computer-readable program 
medium having instructions executable by a processor to synchronizing data on devices 
communicating with a client system ([0035], lines 5-10) with data on a server ([0035], 
lines 5-10), the computer readable medium comprising: 

Instructions for receiving a notification that a device ([0082], lines 1-5), in 
communication with a client system via a USB connection ([0041], lines 1-2, specifically 
USB connection)", 

"instructions for mapping, responsive to receipt of the notification ([0082], lines 1- 
12, where the notification causes the device to be mapped), the device into a user 

session hosted by a server ([0082], lines 3-12, where the client device, PDA, is mapped 
into a user session hosted by a server, [0092], lines 1-13), communicating with said 
client system via a presentation-level protocol ([0044], lines 2-5, specifically HTTP); 

instructions for executing, by said server within the user session, an instance of 
an application ([0092], lines 1-13, specifically integration servlet); and 

instructions for synchronizing a collection of data on said device with a collection 
of data accessible to said user session as a result of the execution of said application 
instance ([0082], lines 3-12)". 
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Berger did not explicitly state: a device "is bound in part to a port number within a 
virtual communication channel". 

However, USB Spec disclosed: a device "is bound in part to a port number (pg 
33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within a virtual 
communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication Flow, lines 
1-6, where the communication is a virtual channel between the client software in the 
host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

1 1 . With respect to Claim 34, Berger disclosed: "A computer-readable medium 
having instructions executable by a processor to synchronize data on a device, in 
communication with a client system, with a collection of data accessible from a server 
([0035], lines 5-10), the computer readable medium comprising: 

Instructions for determining the identity of a device in communication with the 
client system ([0093], lines 4-6) via a USB connection ([0041], lines 1-2), said client 
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system communicating witli a server using a presentation-level protocol ([0044], lines 2- 
5, specifically HTTP); 

instructions for determining that the device is a member of a registered device 
class ([0090], lines 1-5, where a device is part of the class of devices that will invoke an 
agent core if the HotSync process is started); 

instructions for creating a notification indicating that the device is in 
communication with the client ([0090], lines 1-5, where a HotSync trigger is started)", 

"instructions for directing the notification to an instance of an application 
executing within a user session hosted by a server ([0091], lines 1-6, where the agent 
core connects to the integration servlet and delivers a message requiring 
synchronization); and 

instructions for synchronizing a collection of data on said device in 
communication with the client system with a collection of data accessible to said server 
as a result of the execution of said application instance ([0082], lines 3-12)". 

Berger did not explicitly state: "and that the device is bound in part to a port 
number within a virtual communication channel". 

However, USB Spec disclosed: "and that the device is bound in part to a port 
number (pg 33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within 
a virtual communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication 
Flow, lines 1-6, where the communication is a virtual channel between the client 
software in the host and the functional interfaces of the device)". 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

12. With respect to Claim 40, Berger disclosed: "A method for synchronizing data on 
a device in communication with a client system ([0035], lines 5-10), said method 
comprising: 

determining the identity of a device in communication with the client system 
([0093], lines 4-6) via a USB connection ([0041], lines 1-2); 

determining that the device is a member of a registered device class ([0090], 
lines 1-5, where a device is part of the class of devices that will invoke an agent core if 
the HotSync process is started); 

creating a notification indicating that the device is in communication with the 
client system ([0090], lines 1-5, where a HotSync trigger is started)", and 

"directing the notification to an application executing on a server ([0091], lines 1- 
6, where the agent core connects to the integration servlet and delivers a message 
requiring synchronization) communicating with the client system via a presentation level 
protocol ([0044], lines 2-5, specifically HTTP); and 
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synchronizing a collection of data on said device with a collection of data 
accessible from said server as a result of the execution of said application ([0082], lines 
3-12)". 

Berger did not explicitly state: "and that the device is bound in part to a port 
number within a virtual communication channel". 

However, USB Spec disclosed: "and that the device is bound in part to a port 
number (pg 33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within 
a virtual communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication 
Flow, lines 1-6, where the communication is a virtual channel between the client 
software in the host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

1 3. With respect to Claim 44, Berger disclosed: "A system for synchronizing data on 
a device in communication with a client system ([0035], lines 5-10), comprising: 
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a client system communicating with a server system ([0082], lines 3-7) via a 
presentation-level protocol ([0044], lines 2-5, specifically HTTP), said client system 
including an event manager ([0090], lines 1-5, specifically HotSync Manger) to generate 
event notifications ([0090], lines 1-5, specifically a HotSync Trigger) based on a 
communication received from a device interfacing with said client system ([0090], lines 
1-5, where, in response to communication from a PDA, the HotSync Manager starts a 
HotSync Trigger) via a USB connection ([0041], lines 1-2) via a USB connection ([0041], 
lines 1-2); 

the device in communicating with said client system ([0041], lines 1-2), and 
having a collection of data ([0041], lines 1-2)", and 

"the server system communicating with said client system ([0082], lines 3-7) and 
executing an application used to synchronize the collection of data on said device with a 
collection of data accessible to said server ([0092], lines 5-10)". 

Berger did not explicitly state: "said device bound in part to a port number within 
a virtual communication channel". 

However, USB Spec disclosed: "said device bound in part to a port number (pg 
33, 5.3.1 Device Endpoints, lines 1-8, specifically endpoint numbers) within a virtual 
communication channel (pg 32, Fig 5-9 and pg 31, 5.3 USB Communication Flow, lines 
1-6, where the communication is a virtual channel between the client software in the 
host and the functional interfaces of the device)". 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 

14. With respect to Claim 46, Berger disclosed: "A method for synchronizing data on 
a device in communication with a client system ([0035], lines 5-10), said method 
comprising: 

providing a client system communicating with a server via a presentation-level 
protocol ([0044], lines 2-5, specifically HTTP); 

intercepting at least one device enumeration method in a session hosted by the 
server ([0090] - [0092], when a user starts the HotSync process, the HotSync Manager 
initiates a trigger to start an agent core, which connects to an integration servlet to 
commence synchronization with the server), said enumeration method enumerating at 
least one device communicating with the client ([0082], lines 1-5); 

receiving notification ([0082], lines 1-5)", and 

"mapping, responsive to receipt of the notification ([0082], lines 1-12, where the 
notification causes the device to be mapped), said at least one device into a user 
session hosted by the server based on the results of said enumeration method ([0082], 



Application/Control Number: 1 0/71 1 ,699 Page 1 5 

Art Unit: 2451 

lines 3-12, wliere tlie client device, PDA, is mapped into a user session hosted by a 
server, [0092], lines 1-13), said user session including an executing instance of an 
application ([0082], lines 3-12); and 

synchronizing a collection of data on said at least one device with a collection of 
data accessible from said user session as a result of the execution of said application 
instance ([0082], Lines 3-12)". 

Berger did not explicitly state: "receiving notification that the at least one device is 
bound in part to a port number within a virtual communication channel". 

However, USB Spec disclosed: "receiving notification that the at least one device 
is bound in part to a port number (pg 33, 5.3.1 Device Endpoints, lines 1-8, specifically 
endpoint numbers) within a virtual communication channel (pg 32, Fig 5-9 and pg 31, 
5.3 USB Communication Flow, lines 1-6, where the communication is a virtual channel 
between the client software in the host and the functional interfaces of the device)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the system of Berger with the teachings of USB Spec to include 
support for binding a device to a port number within a virtual communication channel. 
Motivation to combine these references comes from the USB Spec disclosing the actual 
workings of USB communications disclosed in Berger. While Berger disclosed USB 
communication, it does not explicitly state the details of USB communications which are 
disclosed in the USB Spec which provides the specification for USB communication. 
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1 5. With respect to Claims 1 0 and 33, the combination of Berger and USB Spec 
disclosed: "further comprising: binding, at the client system, an identifier of the virtual 
communication channel to a mapping request (USB Spec, pg 34, 5.3.1 .1 Endpoint Zero 
Requirements, lines 1-14, and pg 242, 9.1.1.4 Address, lines 1-5, where the host 
system sets the address, or identifier, of the communication channel) prior to mapping 
the device to a user session (USB Spec, pg 34, 5.3.1 .1 Endpoint Zero Requirements, 
lines 1-14, where has its address set and is configured before it can be used by client 
software)". 

16. With respect to Claim 1 1 , the combination of Berger and USB Spec disclosed: 
"The method of claim 1 wherein the client system is a proxy client (Berger, [0082], lines 
3-7, where the client system, or workstation, acts as a proxy between the PDA and 
server)". 

1 7. With respect to Claim 1 2, the combination of Berger and USB Spec disclosed: 
"The method of claim 1 1 wherein the proxy client is hosted on the same server 
supporting the user session (Berger, [0045], lines 1-3, where the web server servers as 
a front end and acts as the proxy client to access the application server)". 

1 8. With respect to Claim 1 3, the combination of Berger and USB Spec disclosed: 
"The method of claim 1 1 wherein the proxy client is hosted on a different server than the 
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server supporting the user session (Berger, [0082], lines 3-7, wliere tlie workstation, or 
proxy, and the server are separated by an internet connection)". 

1 9. With respect to Claims 20 and 45, the combination of Berger and USB Spec 

disclosed: "wherein said event manager is a Plug and Play event manager and said 
event notification Is a Plug and Play event notification (USB Spec, pg 22, 4.8.2.1, Hubs, 
lines 1-3, where USB devices are plug and play)". 

20. With respect to Claim 47, the combination of Berger and USB Spec disclosed: 
"The method of claim 46 wherein said device in communication with the client system Is 
communicating over a USB connection (Berger, [0041], lines 1-2, specifically USB 
connection)". 

21. Claims 2, 5, 15, 26, 35, 35 and 43 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Berger and USB Spec in view of Wright (US 7,024,501 
B1) and Adderman (US 6,961,942 B1). 

22. With respect to Claim 2, the combination of Berger and USB Spec did not 
explicitly state: "wherein mapping the device further comprises mapping a device 
communicating with the client system via a WI-FI communication protocol". 

However, Wright disclosed: "wherein mapping the device further comprises 
mapping a device communicating with the client system via a WI-FI communication 
protocol (Col. 6, lines 22-25)". 



Application/Control Number: 1 0/71 1 ,699 Page 1 8 

Art Unit: 2451 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of Wright to include support for WI-FI. Motivation to combine these 
references comes from Adderman where: "it is increasingly recognized that certain 
advantages arise from the elimination of cables and wires to Interconnect devices. Such 
advantages include ease of configuration and reconfiguration, due to the elimination of 
the need to physically add, remove, or displace a physical medium. Furthermore, space 
that would ordinarily be used for device interconnection media may be given to other 
uses. Significantly, device mobility is increased through the use of wireless connections" 
(Col. 1, lines 17-27). Therefore by combining the references, one can increase device 
mobility by using wireless connections. 

23. With respect to Claims 5, 15, 26, 35 and 43 the combination of Berger and USB 
Spec did not explicitly state: "wherein said device communicates with the client system 
using a wireless USB/ultra-wideband wireless communication protocol". 

However, Wright disclosed: "wherein said device in communication with the client 
system communicates using a wireless USB/ultra-wideband wireless communication 
protocol (Col. 2, line 56 - Col. 3, line 5, where a wireless device such as a PDA is in 
wireless communication with a controller, and this can be a USB system and Col. 6, 
lines 1 1-13 where ultra wideband can also be used)" 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger with the teachings of 
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Wright to include support for wireless USB/ultra-wldeband. Motivation to combine these 
references comes from Adderman where: "It Is Increasingly recognized that certain 
advantages arise from the elimination of cables and wires to Interconnect devices. Such 
advantages Include ease of configuration and reconfiguration, due to the elimination of 
the need to physically add, remove, or displace a physical medium. Furthermore, space 
that would ordinarily be used for device Interconnection media may be given to other 
uses. Significantly, device mobility Is Increased through the use of wireless connections" 
(Col. 1, lines 17-27). Therefore by combining the references, one can Increase device 
mobility by using wireless connections. 

24. Claims 3-4, 16-17, 27-28, 36-37 and 41-42 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Berger and USB Spec in view of Adderman (US 
6,961,942 B1). 

25. With respect to Claims 3, 1 6, 27, 36 and 41 , the combination of Berger and USB 
Spec did not explicitly state: "wherein mapping the device further comprises a device 
communicating with the client system via an IR serial communication protocol". 

However, Adderman disclosed: "wherein mapping the device further comprises a 
device communicating with the client system via an IR serial communication protocol 
(Col. 1, lines 29-33)". 

It would have been obvious to one of ordinary skill In the art at the time of the 
Invention to modify the data synchronization system of Berger with the teachings of 
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Adderman to include support for IR serial communication. Motivation to combine these 
references comes from Adderman where: "it is increasingly recognized that certain 
advantages arise from the elimination of cables and wires to interconnect devices. Such 
advantages include ease of configuration and reconfiguration, due to the elimination of 
the need to physically add, remove, or displace a physical medium. Furthermore, space 
that would ordinarily be used for device interconnection media may be given to other 
uses. Significantly, device mobility is increased through the use of wireless connections" 
(Col. 1, lines 17-27). Therefore by combining the references, one can increase device 
mobility by using wireless connections. 

26. With respect to Claims 4, 1 7, 28, 37 and 42, the combination of Berger and USB 
Spec did not explicitly state: "wherein said device in communicates with the client 
system using a Bluetooth serial communication protocol". 

However, Adderman disclosed: "wherein said device in communicates with the 
client system using a Bluetooth serial communication protocol (Col. 1, lines 47-48)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger with the teachings of 
Adderman to include support for IR serial communication. Motivation to combine these 
references comes from Adderman where: "it is increasingly recognized that certain 
advantages arise from the elimination of cables and wires to interconnect devices. Such 
advantages include ease of configuration and reconfiguration, due to the elimination of 
the need to physically add, remove, or displace a physical medium. Furthermore, space 
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that would ordinarily be used for device interconnection media may be given to other 
uses. Significantly, device mobility is increased through the use of wireless connections" 
(Col. 1, lines 17-27). Therefore by combining the references, one can increase device 
mobility by using wireless connections. 

27. Claims 6, 9, 18, 21, 22, 29, 32 and 38-39 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Berger and USB Spec in view of North (US 7,325,026 
B1). 

28. With respect to Claim 6, the combination of Berger and USB Spec disclosed: 
"The method of claim 1 further comprising: synchronizing a collection of data on said 
device with a collection of data accessible from said user session as a result of the 
execution of said application instance ([0082], lines 3-12)". 

The combination of Berger and USB Spec did not explicitly state: "that uses 
socket communication for inter-process communications; and hooking a socket call 
within the user session". 

However, North disclosed: "that uses socket communication for inter-process 
communications (Col. 2, lines 9-12); and hooking a socket call within the user session 
(Col. 2, lines 9-12)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
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communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
1 2). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

29. With respect to Claim 9, the combination of Berger and USB Spec disclosed: 
"The method of claim 1 further comprising: synchronizing a collection of data on said 
device with a collection of data accessible from said user session as a result of the 
execution of an application ([0082], lines 3-12)". 

The combination of Berger and USB Spec did not explicitly state: "that uses 
socket communication for inter-process communications; and hooking a socket call on 
the server". 

However, North disclosed: "that uses socket communication for inter-process 
communications (Col. 2, lines 9-12); and hooking a socket call on the server (Col. 2, 
lines 9-12)". 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

30. With respect to Claim 18, the combination of Berger, USB Spec disclosed: "The 
method of claim 14 further comprising: directing the notification to an instance of an 
application (Berger, [0082], lines 1-12)" Berger did not explicitly state: "that uses socket 
communication for inter-process communications; and hooking a socket call within the 
user session". 
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However, North disclosed: "that uses socket communication for inter-process 
communications (Col. 2, lines 9-12; and for hooking a socket call within the user session 
(Col. 2, lines 9-12)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

31 . With respect to Claim 21 , the combination of Berger and USB Spec disclosed: 
"The system of claim 19 further comprising: the application instance synchronizing the 
collection of data on the client-attached device and the collection of data accessible 
from the server session (Berger, [0082], lines 3-12)" 
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The combination of Berger and USB Spec did not explicitly state: "an application 
instance using socket communication for inter-process communications", or "and 
hooking a socket call made by the application instance". 

However, North disclosed: "an application instance using socket communication 
for inter-process communications (Col. 2, lines 9-12)" and "and hooking a socket call 
made by the application instance (Col. 2, lines 9-12)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
1 2). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 
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32. With respect to Claim 22, the combination of Berger, USB Spec and North 
disclosed: "The system of claim 21 wherein the socket call is hooked within the user 
session (North, Col. 2, lines 9-12)". 

33. With respect to Claim 29, the combination of Berger, USB Spec disclosed: 
"instructions for synchronizing a collection of data on said device with a collection of 
data accessible to the user session including instructions ([0082], lines 3-12)" 

Berger did not explicitly state: "instructions for executing an instance of an 
application using socket communication for inter-process communications", or "for 
hooking a socket call within the session". 

However, North disclosed: "instructions for executing an instance of an 
application using socket communication for inter-process communications (Col. 2, lines 
9-12)", and "for hooking a socket call within the session (Col. 2, lines 9-12)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
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monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

34. With respect to Claim 32, the combination of Berger and USB Spec disclosed: 
"The computer readable medium of claim 25 further comprising: instructions for 

synchronizing a collection of data on said device in communication with the client 
system with a collection of data accessible to the user session including instructions 
([0082], lines 3-12)". 

The combination of Berger and USB Spec did not explicitly state: "instructions for 
executing an instance of an application using socket communication for inter-process 
communications", "for hooking a socket call on the server console". 

However, North disclosed: "instructions for executing an instance of an 
application using socket communication for inter-process communications (Col. 2, lines 
9-12)" and "for hooking a socket call on the server console (Col. 2, lines 9-12)" 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
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Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

35. With respect to Claim 38, the combination of Berger, USB Spec disclosed: "The 
computer readable medium of claim 34 further comprising: instructions for directing the 
notification to an instance of an application (Berger, [0082], lines 1-12)" and "instructions 
for synchronizing a collection of data on said device with a collection of data accessible 
to the user session including instructions ([0082], lines 3-12)". 

Berger did not explicitly state: "instructions for executing an instance of an 
application using socket communication for inter-process communications", or "for 
hooking a socket call within the session". 

However, North disclosed: "instructions for executing an instance of an 
application using socket communication for inter-process communications (Col. 2, lines 
9-12)", and "for hooking a socket call within the session (Col. 2, lines 9-12)". 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for using socket calls for inter-process 
communications and to hook socket calls within a session. Motivation to combine these 
comes from sockets being the de facto standard for inter-process communications. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 

36. With respect to Claim 39, the combination of Berger, USB Spec and North 
disclosed: "The computer readable medium of claim 38 wherein instructions for hooking 
include instructions for hooking the socket call is on the server console (Col. 2, lines 9- 
12)". 



Application/Control Number: 1 0/71 1 ,699 Page 30 

Art Unit: 2451 

37. Claims 7-8, 23-24 and 30-31 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Berger, USB Spec and North in view of Jones (US 7,051,108 
B1). 



38. With respect to Claims 7, 23 and 30, the combination of Berger, USB Spec and 
North did not explicitly state: "wherein said hooking is virtual loop-back address 
hooking". 

However, Jones disclosed: "wherein said hooking is virtual loop-back address 
hooking (Col. 2, lines 44-50, where a hook is used to intercept local, or loopback, 
communications before they are sent to the network)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger, USB Spec and North 
with the teachings of Jones to include support for virtual loop back address hooking. 
Motivation to combine these comes from Jones, where "An advantage of this approach 
is that the connection oriented protocol is bypassed for data transfer only when 
connection oriented protocol is not necessary, namely when the connection is local. 
However, if the connection is not local, a conventional socket connection is formed. 
Thus, performance for local connections is greatly improved without having to rewrite 
applications to use sockets that do not use connection oriented protocol, such as UNIX- 
domain sockets. In addition, local and network clients are supported by the invention." 
(Col. 2, lines 56-65). Therefore by combining the references, the overhead associated 
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with using a connection oriented protocol is bypassed for local connections where it is 
unnecessary, thus improving local transfer performance. 

39. With respect to Claims 8, 24 and 31 , the combination of Berger, USB Spec and 
North did not explicitly state: "wherein said hooking is virtual IP address hooking". 

However, Jones disclosed: "wherein said hooking is virtual IP address hooking 
(Col. 2, lines 44-50, where a hook is used to intercept local communications, local 
communications being on a virtual IP address since there is no physical interface 
associated with the local address)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger, USB Spec and North 
with the teachings of Jones to include support for virtual address hooking. Motivation to 
combine these comes from Jones, where "An advantage of this approach is that the 
connection oriented protocol is bypassed for data transfer only when connection 
oriented protocol is not necessary, namely when the connection is local. However, if the 
connection is not local, a conventional socket connection is formed. Thus, performance 
for local connections is greatly improved without having to rewrite applications to use 
sockets that do not use connection oriented protocol, such as UNIX-domain sockets. In 
addition, local and network clients are supported by the invention." (Col. 2, lines 56-65). 
Therefore by combining the references, the overhead associated with using a 
connection oriented protocol is bypassed for local connections where it is unnecessary, 
thus improving local transfer performance. 
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40. Claim 48 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Berger and USB Spec in view of North and further in view of Chu (US 6,970,924 
B1). 

41 . With respect to Claim 48, tlie combination of Berger and USB Spec did not 
explicitly state: "wherein said enumeration method is intercepted via a hook DLL". 

However, North disclosed: "wherein said enumeration method is intercepted via a 
hook (Col. 2, lines 9-12)" 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec with the 
teachings of North to include support for hooking socket calls within a session. 
Motivation also comes from North, where "Upon a completion of call, control is returned 
and the application is updated to reflect the actual performance of the call. The call is 
also completed notwithstanding any termination of communication monitoring, retaining 
the transparency of the monitoring system to the application. One embodiment 
monitors TCP/IP communications. More particularly, socket interface routines 
corresponding to various socket calls made by an application are hooked, and the 
performance of these socket calls is captured and recorded for analysis" (Col. 2, lines 3- 
12). Therefore by combining the references, one can monitor the performance of the 
socket calls transparently to the application. 
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The combination of Berger and North did not explicitly state: "a hook DLL". 
However, Chu disclosed: "a hook DLL (Col. 5, lines 3-9, specifically hook DLL 
ARHook32.dll)". 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the data synchronization system of Berger and USB Spec in view of 
North with the teachings of Chu to include support for using a hook DLL. Motivation to 
combine these references comes from Adermann, where: "Winsock (Microsoft brand 
"WINDOWS" Sockets) is a programming interface (API) that traditionally allows a 
"WINDOWS" application to access the TCP/IP protocol. Winsock routines are ordinarily 
implemented as a dynamic link library" (Col. 6, lines 46-51). Therefore, by combining 
the references to implement monitoring of TCP/IP communications by hooking socket 
calls (North, Col. 2, lines 8-12), one can follow traditional standards by implementing the 
hook as a dynamic link library. 

Response to Arguments 

42. Applicant's arguments, see pg 12, II. Claim Objections, filed 17 November 2008, 
with respect to Claim Objections have been fully considered and are persuasive. The 
Objection of Claims 31 and 39 has been withdrawn. 

43. Applicant's arguments, see pg 12, III Rejections under 35 USC 102, filed 17 
November 2008, with respect to the rejection(s) of claim(s) 1 , 1 1-13, 14, 19, 25, 34, 40, 
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44 and 46 under 35 USC 102 have been fully considered and are persuasive. 
Therefore, the rejection has been withdrawn. However, upon further consideration, a 
new ground(s) of rejection is made in view of Universal Serial Bus Specification, 
Revision 2.0 (April 27, 2000). 

44. Applicant's arguments, see pg 13, IV Rejections under 35 USC 103, filed 17 
November 2008, with respect to the rejection(s) of claim(s) 2-10, 15-18, 20-24, 26-33, 
35-39, 41-43, 45 and 47-48 under 35 USC 103 have been fully considered and are 
persuasive. Therefore, the rejection has been withdrawn. However, upon further 
consideration, a new ground(s) of rejection is made in view of Universal Serial Bus 
Specification, Revision 2.0 (April 27, 2000). 

Conclusion 

45. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 

§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 

CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
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shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to MATTHEW S. LINDSEY whose telephone number is 
(571)270-381 1 . The examiner can normally be reached on Mon-Thurs 7-5, Fridays 7- 
12. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

MSL 

2/26/2009 

/John Follansbee/ 

Supervisory Patent Examiner, Art Unit 2451 



